1. Field of the Invention
This invention relates to the field of computer networking, and in particular to a low complexity information exchange management system.
2. Description of the Related Art
Internetworking of high-performance computers has become the focus of much attention in the data communications industry. Performance improvements in processors and peripherals, along with the move to distributed architectures such as client/server, have spawned increasingly data-intensive and high-speed networking applications, such as medical imaging, multimedia, and scientific visualization. However, the interconnections between the systems and their input/output devices cannot keep up with the blinding data rates, nor can they provide the distances needed for local area networks spanning campus-wide areas.
According to "Amdahl's Law", a megabit per second of input/output (I/O) capability is needed for every MIPS of processor performance. Current communications standards top out at just over 100 megabits per second, not nearly fast enough, as technical computing applications already demand processors exceeding 1,000 MIPS. The deficiencies in current transmission rates results in the communications channel becoming a bottleneck to system performance.
A new protocol known as Fibre Channel is 10 to 250 times faster than existing networks, transmitting at rates exceeding 1 Gbps in both directions simultaneously. It defines standard media and signaling conventions for transporting data in a serial fashion, it provides an error correcting channel code and a frame structure for transporting the data, it sets out a flow control methodology, creates some common services, and supports interfaces to existing higher level protocols such as SCSI (small computer system interface). The Fibre Channel protocol can be applied to various network topologies including point-to-point, ring, and switched. The Fibre Channel protocol is being proposed as an ANSI (American National Standards Institute, Inc.) standard, and a multitude of reference material is readily available at http://www.fibrechannel.com.
Communication across the Fibre Channel is provided using data frames. Consecutive data frames travelling in one direction form a sequence, and a group of related sequences combines to form an exchange. The higher level protocols supported by Fibre Channel perform "operations" such as: open, read, write, close, etc. An exchange may correspond to one of these operations. Each active sequence in an exchange is provided with a unique sequence identifier. This and other limitations on the sequence identifier are set forth in the Fibre Channel standard FC-PH (X3.269-199X revision 12) which is hereby incorporated by reference.
Each data frame incorporates a frame header immediately following a start-of-frame delimiter. The frame header among other things includes the sequence identifier. The following table describes the structure of the frame header:
______________________________________ Word Byte 3 Byte 2 Byte 1 Byte 0 ______________________________________ 0 R.sub.-- CTL D.sub.-- ID 1 Reserved S.sub.-- ID 2 TYPE F.sub.-- CTL 3 SEQ.sub.-- ID DF.sub.-- CTL SEQ.sub.-- CNT 4 OX.sub.-- ID RX.sub.-- ID 5 RLTV.sub.-- OFF ______________________________________
The identity of each data frame is uniquely specified by the S.sub.-- ID, D.sub.-- ID, SEQ.sub.-- ID, SEQ.sub.-- CNT, and Sequence Context values. The OX.sub.-- ID and RX.sub.-- ID fields (generically referred to as the X.sub.-- ID fields) may be used by a node to provide a locally assigned value to use in place of the S.sub.-- ID, D.sub.-- ID, and SEQ.sub.-- ID values to identify frames in a sequence. A node makes use of these ID values in an implementation-dependent manner to uniquely identify open sequences. The description of each of the fields in the frame header is now provided.
R.sub.-- CTL is a one byte field for routing control. It contains routing bits and information bits that categorize the frame function. Routing bits differentiate frames based on function or service within a node. These may indicate frames related to a specific upper level protocol operation or specify that the frame payload is to be directed to a video buffer (for example) without passing through the main data store. The information bits interpretation is dependent upon the routing bits field value, and may be an information category (i.e. solicited/unsolicited data/control/status) or a command.
Each node has an address identifier which is unique within the local address domain. D.sub.-- ID is a three byte field that contains the address identifier specifying the destination of the frame, and S.sub.-- ID is a three byte field that contains the address identifier specifying the source frame.
TYPE is a one byte field which is generally provided for specifying the data structure type (determined by the higher level protocol) of the frame content, but may also be used for indicating a reason code for a rejected frame. F.sub.-- CTL is a three byte field that contains control information relating to the frame content and sequence flow control. Various flags are provided to indicate the status of the sequence and other flow control functions. The Sequence Context flag is in the F.sub.-- CTL field, and it indicates whether the S.sub.-- ID or D.sub.-- ID node initiated the sequence.
SEQ.sub.-- ID is a one byte field assigned by the sequence initiator. The SEQ.sub.-- ID is unique for a specific D.sub.-- ID and S.sub.-- ID pair while the sequence is open. If the sequence initiator initiates a new sequence for the same exchange before receiving the final acknowledgement for the previous sequence, it is termed a streamed sequence. If streamed sequences occur, the sequence initiator must use X+1 different consecutive SEQ.sub.-- IDs where X is the number of open sequences per exchange. If consecutive non-streamed sequences for the same exchange occur during a single sequence initiative, the sequence initiator must use a different SEQ.sub.-- ID for each consecutive sequence. This may be accomplished by alternating between two SEQ.sub.-- ID values.
DF.sub.-- CTL is a one byte field that specifies the presence of optional headers at beginning of the data field for data frames. SEQ.sub.-- CNT is a two byte field that indicates the sequential order of data frame transmission within a single sequence or multiple consecutive sequences for the same exchange. The sequence count of the first data frame of the first sequence of the exchange shall be binary zero, and the sequence count of each subsequent data frame in the sequence shall be incremented by one. If a sequence is streamed the sequence count of the first data frame of the sequence is incremented by one from the sequence count of the last data frame of the previous sequence (i.e. continuously increasing). If a sequence is non-streamed, the starting sequence count may be continuously increasing or binary zero. The sequence count wraps around to zero after reaching a value of 65535.
OX.sub.-- ID is a two byte field that identifies the exchange ID assigned by the originator of the exchange. Each exchange is assigned an identifier unique to the originator or originator-responder pair. An originator exchange status block associated with the OX.sub.-- ID is used to track the progress of a series of sequences which comprises an exchange. Similarly, RX.sub.-- ID is a two byte field assigned by the responder to provide a unique, locally meaningful identifier at the responder for an exchange established by an originator and identified by an OX.sub.-- ID. A responder exchange status block associated with the RX.sub.-- ID is used to track the progress of a series of sequences which comprises the exchange.
RLV.sub.-- OFF is a four byte field which indicates the relative displacement of the first byte of each frame's payload with reference to the base address of the information category. Providing a value for this field is optional.
The high data rates require that a large part of the Fibre Channel protocol be handled by hardware. The hardware implementation may incur unwanted cost and complexity, particularly if a large number of concurrent data exchanges are to be supported. Each sequence of each data exchange must be tracked by the network interface so that the interface can commence, conduct, and conclude information exchanges in an orderly fashion, conforming to the specified control flow and verifying the validity of each received data frame. The tracking information for each exchange is stored in a corresponding entry in an exchange table. It is desirable to provide a low-complexity method for supporting a large number of concurrent data exchanges.